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Introduction 


Clint  and  Hoare  [2]  gave  a proof  rule  for  functions  (without  side  effects)  which  later  was 
shown  by  Ashcroft  [1]  to  be  unsound.  The  way  of  avoiding  the  unsoundness  suggested  in 
[1]  seems  unattractive  in  that  it  requires  "an  unconventional  interpretation  for  functional 
notation,"  while  other  proof  rules  that  have  been  proposed  for  functions  are  more  complicated 
(e  g.,  as  in  [7])  or  require  proofs  of  termination  for  functions.  This  paper  suggests  a simple 
modification  to  Clint  and  Hoare’s  proof  rule--an  additional  "consistency  premise" — which  makes 
it  sound  without  requiring  proofs  of  termination.  Although  proving  termination  is  in  most 
cases  a worthy  goal,  one  may  wish  to  consider  functions  that  fail  to  terminate  because  they 
exit  abnormally  by  a jump  to  an  external  label  [2 J.  For  such  functions  the  present  proof  rule 
will  be  especially  useful.  It  also  permits  a simpler  algorithm  for  generating  verification 
conditions  than  that  described  in  [7],  and  has  been  implemented  by  the  author  in  a 
verification  condition  generator  at  Information  Sciences  Institute. 

The  new  proof  rule,  like  the  Clint  and  Hoare  rule,  allows  (and  requires)  the  result  of  the 
computation  performed  by  the  body  of  a given  function  f to  be  specified  as  a mathematical 
function1  of  the  input  values,  using  the  name  f as  the  name  of  the  mathematical  function  also. 
In  order  to  make  the  proof  rule  applicable  to  programming  languages  in  which  nondeterministic 
computations  are  expressible,  the  rule  includes  a premise  requiring  that  the  body  of  the 
function  deterministically  computes  its  result  value. 

Following  some  simple  examples  of  use  of  the  new  proof  rule,  we  give  versions  of  the  rule 
adapted  to  the  Pascal  [6]  and  Euclid  [9,11]  languages,  and  conclude  with  a discussion  of  the 
role  in  programming  languages  of  function-like  constructs  which  do  have  side  effects. 


Notation 


Hoare’s  notation  PjS}R,  where  P and  R are  predicates  and  S is  a statement  in  a programming 
language,  will  be  used  to  express  the  assertion  that  if  P is  true  before  the  execution  of  S then 
R is  true  after  the  execution  of  S.  P{S}R  is  vacuously  true  if  S fails  to  terminate.  Rather  than 
considering  this  to  be  a different  kind  of  assertion  from  an  ordinary  predicate,  we  will  assume 
P{S}R  is  defined  as  a predicate  transformer;  e.g.,  in  terms  of  the  predicate  transformer  wlp 
("weakest  liberal  precondition")  defined  in  [4],  we  have  P{S}R  ■ (P  3 wlp(S.R)).  Thus  the 
usual  logical  operators,  including  quantification,  may  be  used  in  conjunction  with  these 
assertions. 

The  notation 


p 

y-*x 

will  be  used  to  denote  the  predicate  which  is  obtained  by  substituting  y for  all  free 
occurrences  of  x in  P. 


Throughout  this  paper  the  term  "function"  will  refer  to  a programming  language  concept  and  the  term 


"mathematical  fimction"  will  refer  to  the  function  concept  in  ordinary  mathematical  ie|Q*,  -ke..  an  aaaocialion  off 


exactly  one  element  from  one  set  with  each  element  of  another  set. 


N IS 

PIT 

I.NAT.  ' ,N|r 

JUS  . ICA 


B i 


VrUon 
$».  .on  □ 

□ 


rm  / 

i/ 


BY 


DISTMIONlfM'IT,  TO 


Dist  ' 

K 


UAL 


A PROOF  RULE  FOR  FUNCTIONS 


Page  2 


r 


Thus,  for  example,  P{x:«e}R  * (P  o Re_>x)- 


The  proof  rule 


A function  is  declared  by  the  schema 


function  f(x)  returns  z;  5 

where  f is  the  function  name,  S is  the  body  of  the  function,  x is  a list  of  formal  parameters 
including  all  of  the  free  non-local  variables  appearing  in  S,  and  z is  the  return  variable  (which 
is  assigned  to  by  one  or  more  statements  in  S).  It  is  assumed  that  S makes  no  assignment  to 
any  of  its  parameters  so  that  there  is  no  possibility  of  side  effects.  Let  P and  R be  predicates 
(P  will  be  referred  to  as  a precondition  and  R as  a postcondition  for  f;  generally  both  P and  R 
; will  depend  on  x and  R will  also  depend  on  z).  F rom 

\ 

(1)  [Consistency!  V*3 z(P  ^ R) 

(2)  1 Determinism [ Vx3zl(P{S)z-=zl) 


(3)  [ Property  of  SJ  Vx(P{S}R> 

we  may  deduce  the  following  implication: 

(4)  [Property  of  fj  Vx(P  3 Rf(xy*z>- 

This  property  (4)  may  be  assumed  in  proving  assertions  about  expressions  containing  calls  of 
the  function  f,  including  those  occurring  within  S itself.  If  other  properties  of  the  function  f 
have  been  added  to  the  proof  system  previously,  then  premise  (I)  should  be  replaced  by 

(V)  [Global  consistency [ V*3z(9  A (P  3 R)) 

where  0 is  the  conjunction  of  all  properties  of  f with  all  occurrences  of  f(x)  replaced  by  z. 

Discussion 


This  proof  rule  differs  from  the  Clint  and  Hoare  rule  mainly  in  the  addition  r-  (1)  (or  (1’))  and 
(2)  as  premises.  The  role  of  (1)  and  (D  is  to  prevent  the  use  of  a postcondition  that  is  so 
strong  that  no  mathematical  function  could  exist  satisfying  (4).  If  each  function  has  associated 
with  it  a single  precondition  and  single  postcondition,  as  for  example  in  the  Euclid  language, 
then  use  of  (1*)  would  be  unnecessary.  However,  one  may  wish  to  state  and  prove  properties 
of  a function  incrementally,  or  by  means  of  a collection  of  "axioms"  about  a whole  set  of 
functions,  as  in  the  algebraic  axioms  method  of  specification  of  an  abstract  data  type  [5].  In 
this  case  (1*)  should  be  used. 
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Premise  (2)  requires  that  the  value  of  z computed  by  S is  some  mathematical  function  of  x;  i.e., 
S computes  z deterministically  from  x.  Without  this  requirement  it  would  be  possible  to  have 
computations  denoted  by  functional  notation  even  though  the  result  of  the  computation  is 
indescribable  as  a mathematical  function  of  its  inputs.  For  languages  in  which  every 
computation  is  deterministic,  such  as  Pascal,  this  premise  is  trivially  satisfied  and  can  be 
ignored.  The  Euclid  language,  however,  permits  a form  of  nondeterminism,  as  will  be  discussed 
below. 

If  S contains  (recursive)  calls  of  f,  then  property  (4)  should  be  added  to  the  proof  system 
before  attempting  to  prove  (3),  so  that  (4)  may  be  used  in  the  proof  of  (3).  Thus  as  a general 
rule,  first  premise  (1)  (or  (l’»  should  be  established  without  using  (4),  then  (4)  may  be  added 
to  the  proof  system,  then  the  proof  of  (3)  may  be  attempted.  If  (3)  is  not  provable,  then 
either  S should  be  modified  or  (4)  should  be  deleted  from  the  proof  system. 


Examples 


In  [1]  the  following  example  was  given  showing  the  unsoundness  of  the  original  rule,  which 
had  only  the  property  of  S,  (3)  as  a premise: 

function  f(x:integer)  returns  z:integer; 
begin  z:*0;  while  true  do  null  end 

P:  TRUE 
R:  FALSE  a z-O 

It  is  possible  to  prove  (3)  (taking  z=0  as  the  invariant  of  the  while  loop),  which  would  give 
Vx(TRUE  ^ (FALSE  a f(x)=0»  or  simply  FALSE  for  the  property  of  f,  so  that  the  addition  of  this 
property  to  the  proof  system  would  make  it  inconsistent.  For  this  P and  R,  however,  the 
consistency  premise  (1)  is  Vx3z(TRUE  :>  (FALSE  a z=0)),  which  reduces  to  FALSE.  Thus  the 
requirement  of  premise  (1)  serves  to  prohibit  the  addition  of  (4)  to  the  proof  system  in  this 
case. 

If  R in  this  example  were  weakened  to  be  just  z*=0,  then  the  consistency  premise  (1)  would  be 
Vx3z(TRUE  = z=0),  which  is  trivially  provable,  and  the  property  Vx(TRUE  r>  f(x)=0),  or  simply 
Vx(f(x)=0),  could  be  added  to  the  proof  system.  The  fact  that  the  body  of  the  function  always 
fails  to  terminate  makes  it  rather  useless,  but  at  least  no  unsoundness  can  arise  from  use  of 
the  property  Vx(f(x)=0)  in  any  proofs. 

To  see  how  the  consistency  premise  (1)  comes  into  play  in  the  verification  of  a useful  function, 
consider  the  example  given  in  [2],  a function  lookup(A,N,z)  which  searches  for  an  element  x 
in  a sorted  array  A of  length  N,  returning  an  index  m such  that  A[m]«x  if  x is  contained  in  A, 
and  jumping  out  to  an  external  label  if  not.  If  we  take  as  pre-  and  postconditions  for  lookup 2 

P:  1<N  a sorted(A,N) 

R:  A[m]«x 


2 


These  ware  the  pre-  and  postcondition*  used  in  [2],  except  for  some  inessential  detail*. 
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then  the  consistency  premise  would  be  VA,N,x3m(l<N  a sorted(A,N)  3 A[m]*x),  which  is  false. 
However,  if  R is  weakened  to  be  3i<  1<*<N  a A[i]»x)  a A[m]«=x,  then  the  resulting  consistency 
premise  is  true  (and  is  trivial  to  prove).  Since  the  weaker  postcondition  is  a more  accurate 
description  of  the  behavior  of  the  function,  the  requirement  of  the  consistency  premise  seems 
to  support  the  use  of  pre-  and  postconditions  to  document  programs  in  a precise  manner, 
aside  from  its  role  in  preventing  inconsistency. 

A simple  example  of  the  necessity  of  using  the  global  consistency  premise  (D  instead  of  (1)  in 
the  case  of  multiple  pre-  and  postconditions  is  the  following: 

function  f(x:integer)  returns  z:integer; 
begin  if  x~0  then  while  true  do  null  else  z:«x  end 

Pj:  x>0 
Rj: z>0 
P2:  x<0 
R2:  z<0 

From  Pj  and  Rj  we  obtain  the  property  Vx(x>0  3 f(x)>0)  and  from  P2  and  R2  we  would  obtain 
the  contradictory  property  Vx(x<0  3 f(x)<0)  if  only  premise  (1)  were  required.  However,  (l’>  is 
Vx3z((x20  a z>0)  a (x<0  s z<0)),  which  is  false,  prohibiting  the  adoption  of  the  second 
property. 

To  illustrate  the  role  of  the  determinism  premise  (2),  suppose  that  the  construct  SI  or  S2 
means  that  either  statement  SI  or  statement  S2  is  to  be  executed,  the  choice  being  made 
nondeterministically  [10J.  Formally, 

PJSJ  or  S2}R  « P{S1}R  a P{S2}R; 

in  particular, 

P{x:«el  or  x:-e2}R  * (P  3 Re j _,x  a Re2-,x^ 

Then  if  we  attempt  to  write 

function  f(x:integer)  returns  z:integer; 
begin  z 0 or  z :«  1 end; 

we  obtain  as  premise  (2) 

Vx3z1(P3(z1-0az1«1)> 

which  is  false  for  any  satisfiable  P.  Therefore  this  nondeterministic  assignment  to  z could  not 
be  used  as  a function  body. 

Pascal  functions 


The  proof  rule  given  in  [6]  for  Pascal  functions  was  based  on  the  rule  of  [2]  and  has  the 
same  problem  of  unsoundness.  The  following  differs  from  the  rule  given  in  [6]  in  the  addition 
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of  the  consistency  premises  (PI)  and  (PI’)  and  in  permitting  postconditions  to  refer  to  initial 
values  of  parameters  (parameters  to  functions  in  Pascal  are  value-parameters). 

A function  it  declared  by  the  schema 


function  f(LhT;  S 

where  L is  a Ust  of  identifiers  and  types,  T is  a type  name  (the  type  of  the  return  value  of  the 
function,  for  which  the  name  of  the  function,  f,  is  used),  and  S is  a statement.  Let  x be  the 
Ust  of  parameters  declared  in  L,  and  let  y be  the  Ust  of  nonlocal  variables  occurring  within  S 
(impUcit  parameters).  Given  predicates  P and  R,  where  f does  not  occur  free  in  P and  none  of 
the  variables  of  x occurs  free  in  R (and  occurrence  in  R of  primed  variables  x'  denotes  initial 
values  of  the  parameters  x),  then  from 

(PI)  / Consistency / V*,y3 f(P  z>  Rx^x>) 

and 

(P2)  / Property  of  Sf  Vx,y,x'((x~x'  A P){S}R) 

we  may  deduce  the  following  impUcation: 

(P3)  / Property  of  f]  Vx,y(P  = Rf(x>yy>f% 

Note  that  the  expUcit  parameter  Ust  x has  been  extended  by  the  impUcit  parameters  y,  that  x 
may  not  contain  any  variable  parameters  (specified  by  var)  and  that  no  assignments  to 
nonlocal  variables  may  occur  within  S.  It  is  property  (P3)  that  may  be  assumed  in  proving 
assertions  about  expressions  containing  calls  of  the  function  f,  including  those  occurring 
within  S itself  and  in  other  declarations  in  the  same  block.  In  addition,  assertions  generated 
by  the  parameter  specifications  in  L may  be  used  m proving  assertions  about  S.  If  other 
properties  of  the  function  f have  been  added  to  the  proof  system  previously,  premise  (PI) 
should  be  replaced  by 

(Pl’)fGlobal  consistency / 'ix,y3f(Q  A (P  =>  Rx-,x>)) 

where  Q is  the  conjunction  of  aU  properties  of  f with  aU  occurrences  of  f(x,y)  replaced  by  f. 


Euclid  functions 


In  the  Euclid  language,  the  definition  of  functions  is  complicated  by  the  possibility  of 
nondeterministic  behavior  of  operations  defined  in  a Euclid  module.  The  abstraction  function 
of  a module  implicitly  defines  an  equality  relation  on  values  of  the  type  defined  by  the  module; 
with  respect  to  this  equality,  operations  of  the  module  may  be  nondeterministic  since  they  may 
behave  differently  for  different  concrete  representations  of  the  same  (abstractly  equal) 
inputs.  Thus  the  premise  requiring  deterministic  computation  is  included  in  the  following  proof 
rule  for  Euclid  functions. 

A function  is  declared  by  the  schema 
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function  f(L)  returns  i:T  • importsfMJ;  pre  P;  post  R;  S 

where  L and  M are  In',  of  identifiers  with  types,  z is  the  return  variable,  T is  a type,  P and  R 
are  predicates,  and  S is  a statement.  Let  x be  the  list  of  parameters  declared  in  L and  y be  the 
list  of  parameters  declared  in  M.  F rom 

(El)  / Consistency / V*,y3 z(P  3 R) 

(E2)  / Determinism / Vx,y3zl(P{S}z=zl) 

and 

(E3)/Property  of  S J Vj e,y(P{S}R) 

we  may  deduce  the  following  implication: 

(E4)  f Property  of  //  Vx,y(P  =>  Rf(Xfy)-n>- 

Note  that  the  definition  of  Euclid  does  not  permit  any  of  the  parameters  x or  y to  be  altered 
(they  are  const  or  readonly.).  It  is  property  (E4)  that  may  be  assumed  in  proving  assertions 
about  expressions  containing  calls  of  the  function  f,  including  those  occurring  within  S itself 
and  in  other  declarations  in  the  same  block.  In  addition,  the  axiom  P{return}F ALSE  and 
assertions  generated  by  * be  specifications  in  L and  M may  be  used  in  proving  assertions  about 
S. 


Conclusions 


We  have  given  a proof  rule  for  functions  without  side  effects,  essentially  the  Clint  and  Hoare 
rule  modified  with  some  additional  premises.  These  additions  eliminate  the  possibility  of 
unsoundness  and  permit  reasoning  about  functions  to  be  carried  out  in  familiar  mathematical 
notation  even  in  cases  in  which  the  body  of  the  function  does  not  terminate  for  some  inputs. 
In  many  common  programming  languages,  what  are  called  functions  have  no  strictures  against 
side  effects  and  thus  are  not  characterizable  by  the  simple  proof  rule  we  have  given.  Proof 
rules  which  have  been  proposed  for  such  "functions"  [3,8]  effectively  treat  them  as  a 
special  Kind  of  procedure  call  and  require  the  introduction  of  new  symbols  to  denote  return 
values.  In  languages  such  as  Pascal  and  Euclid,  any  computations  having  side  effects  would 
have  to  be  programmed  as  procedures,  and  thus  the  proof  rule  for  procedure  calls  would 
apply  directly.  In  most  situations,  this  would  seem  to  be  the  most  satisfactory  way  of 
programming  and  reasoning  about  computations,  as  it  provides  a clear  distinction  between  true 
functions  and  computations  having  side  effects.  It  is  difficult,  however,  to  argue  that  all 
computations  which  have  traditionally  been  programmed  as  "functions"  even  though  they  have 
side  effects  should  instead  be  programmed  as  procedures.  The  Lisp  function  CONS,  for 
example,  has  a side  effect  on  the  free  storage  list,  and  thus  all  Lisp  functions  that  use  CONS 
have  side  effects.  In  the  design  of  future  programming  languages  it  will  probably  be 
necessary  to  retain  some  sort  of  value-returning  procedure  (callable  from  expressions),  but  it 
would  seem  worthwhile  also  to  have  a pure  function  construct  to  which  the  proof  rule 
discussed  in  this  paper  would  be  applicable.  Then  those  computations  which  could  be 
programmed  without  side  effects  could  still  be  characterized  via  the  simple  concepts  of 
mathematical  functions. 
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